Skip to content

CA-408550: XSI-1834: Host netbios name should be added to local hosts file to avoid DNS lookup #6386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 1, 2025

Conversation

liulinC
Copy link
Collaborator

@liulinC liulinC commented Mar 24, 2025

Without adding netbios name into /etc/hosts, a DNS query for localhost name is performed when talks to Domain Controller.

This waste resources, especially when XenServer is monitorred by ControllUP, who perform external auth very frequently

Adding netbios name into /etc/hosts to avoid the DNS query and keep consistent with PBIS

hosts file to avoid DNS lookup

Without adding netbios name into /etc/hosts, a DNS query for
localhost name is performed when talks to Domain Controller.

This waste resources, especially when XenServer is monitorred by
ControllUP, who perform external auth very frequently

Adding netbios name into /etc/hosts to avoid the DNS query and
keep consistent with PBIS

Signed-off-by: Lin Liu <Lin.Liu01@cloud.com>
Signed-off-by: Lin Liu <Lin.Liu01@cloud.com>
@minglumlu
Copy link
Member

Can this be done without touching the "/etc/hosts"? E.g. a configuration for the specific sub process?

@liulinC
Copy link
Collaborator Author

liulinC commented Mar 25, 2025

Can this be done without touching the "/etc/hosts"? E.g. a configuration for the specific sub process?

@lindig
Copy link
Contributor

lindig commented Mar 25, 2025

I agree that this should not be per process but as general as possible. However, it is strange that this is required for efficiency. I consider DNS resolution an OS task and would expect this to be efficient from caching (since DNS has lifetime data) without having to update /etc/hosts.

@liulinC
Copy link
Collaborator Author

liulinC commented Mar 26, 2025

resolution

We do not use local OS cache (we do not have systemd-resolved, or ncsd)

@lindig
Copy link
Contributor

lindig commented Mar 26, 2025

A process ususally calls gethostbyname() and its up to libraries and system configuration how this is resolved - which includes using /etc/hosts. This is configured with /etc/nsswitch.conf.

| true ->
String.split_on_char sep line
|> List.filter (fun x -> x <> name && x <> fqdn)
|> (fun x -> match op with Add -> x @ [name; fqdn] | Remove -> x)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before we add something, should we make sure there is not previous entry for it? That is - should an addition always include a removal of any existing entry such that the new entry is the definitive one? Is that even possible?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Every entry should only exists once for an IP address
  • The order does not really matter
  • We remove the entry and add new one if necessary, to keep unify for Add and Remove operation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this still work when name or fqdn changes? So: the file contains an outdated entry; and the current name or fqdn does not match the previous one.

@robhoes
Copy link
Member

robhoes commented Mar 26, 2025

Is this an enhancement to speed up many AD logins in a short time span? We have another possible solution for that, which is currently still disabled by default pending further testing: AD login caching, which completely avoids reaching out to the AD server if the same login request was made recently. Would that be enough to solve this problem?

@lindig
Copy link
Contributor

lindig commented Mar 26, 2025

The amount of traffic generated by the Controlup XAPI connection via HTTP appears to be related to the number of authentication requests that are required to use the API.
Some API calls seem to require calls back the domain controllers and cause these extra DNS requests.
This could point to a possible problem how the API is used. What forces frequent authentication here? Is Controlup using a new login for each API call?

@liulinC
Copy link
Collaborator Author

liulinC commented Mar 27, 2025

Is this an enhancement to speed up many AD logins in a short time span? We have another possible solution for that, which is currently still disabled by default pending further testing: AD login caching, which completely avoids reaching out to the AD server if the same login request was made recently. Would that be enough to solve this problem?

The cache is good to resolve the issue, and I have already suggested that to customer to give it a try.

However, goes to DNS to resolve local host is totally unnecessary, and is a regression comparing to PBIS needs fix.

@liulinC liulinC added this pull request to the merge queue Apr 1, 2025
Merged via the queue into xapi-project:master with commit 0441299 Apr 1, 2025
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants